@luin any chance we can squeeze in resp3 (dont remember this being supported, but might be wrong) / client side caching here? glad to help!

and another idea is native opentelemetry instrumentation

@luin any chance we can squeeze in resp3 (dont remember this being supported, but might be wrong) / client side caching here? glad to help!

It hasn't been supported 🤣 . For myself, I don't feel that resp3 will bring a lot of real value, and I'm not sure as a driver, what kind of API needs to be provided to support the new features that resp3 brings. Similarly, client side caching does not seem to be as meaningful for a language that uses GC.

But I haven't thought much about this, so open to suggestions! If we want to support resp3, v5 seems to be a good chance to do so.

and another idea is native opentelemetry instrumentation

Can you elaborate a little bit more on this? Does it mean to provide an interface to get the average command execution time or something similar?

Can you elaborate a little bit more on this? Does it mean to provide an interface to get the average command execution time or something similar?

it sort of allows you to perform diagnostics better and get a complete trace of a request when every part of your request chain is instrumented, typically you'd use async_hooks, but can be anything

https://github.com/elastic/apm-agent-nodejs/blob/main/lib/instrumentation/modules/ioredis.js is an example of an existing instrumentation, which can be bridged to opentracing/opentelementry, fed to something like https://github.com/jaegertracing/jaeger for visualization/search

It hasn't been supported 🤣 . For myself, I don't feel that resp3 will bring a lot of real value, and I'm not sure as a driver, what kind of API needs to be provided to support the new features that resp3 brings. Similarly, client side caching does not seem to be as meaningful for a language that uses GC.

I don;t think GC is relevant in terms of client-side caching here, in my opinion main benefit here is lower latency to access information, along with guarantees that information is still what server has. https://redis.io/topics/client-side-caching
for certain queries you can opt-in to cache the response. when server-side data changes - server will notify clients about that and clients will get new info

Resp3 changes response formats and we should mention that. eg. booleans are converted to true/false instead of 1/0: https://redis.io/topics/lua-api#lua-to-resp3-type-conversion

Therefore I'd schedule resp3 with another version later or support opt-out (maybe opt-in using HELLO 3 as resp2 is still the default in redis).

Renamed to the main branch. Published v5.0.0-beta.1.

The biggest thing I could think of for a major version would be changing the default to enableAutoPipelining: true to avoid the potential bottleneck.

Things it would affect:

• select to manually select a db number (1505)
• applications where failures due to networking errors are important to avoid? When not to use enableAutoPipelining? #1377 (comment)
  (In practice, I assume the number of in flight commands would be low if redis is in the same local network)

Yeah I think that makes sense. Let's delay this to the next major release.

Hey @marcbachmann @TysonAndre 👋 , thanks for the contributions to ioredis. I've just invited you to become collaborators on this repository. Feel free to help review new pull requests in the future if you have time (and it doesn't matter at all if you don't have time 😄). Appreciate it 🙏. You can refer to https://github.com/luin/ioredis/blob/main/.github/CONTRIBUTING.md for some notes.

Why disable it by default?

Hey @shaharmor , The option at some level introduces side effects as it consumes resources, especially during a failover, that by default every 5 seconds all nodes may have to be recreated (if cluster slots gives different results). Given that, I think developers need to be aware of this option and only enable it explicitly when they are aware of its purpose. WDYT?